【書評】なぜ、あなたの仕事は終わらないのか #ビジネス書を楽しもう
はじめに
せーのでございます。
誰にも知らせずまったり始めている「ビジネス書」アドベントカレンダー、本日は3日目です。
バックナンバー
本日は中島聡著「なぜ、あなたの仕事は終わらないのか」です。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
【世界を一変させたWindows95の設計思想を生み出した伝説の日本人が教える 人生を制するスピード仕事術】 本書の著者、中島聡氏は、 「ドラッグ＆ドロップ」や「ダブルクリック」などの概念を生み出した 元マイクロソフトの伝説のプログラマーです。...
これは名著ですね。著者の中島聡さんは元マイクロソフトの伝説のプログラマ。Windows95の開発に関わり、IEを世界に広めた男、と言われています。今では当たり前の右クリック、ドラックアンドドロップ、ダブルクリックの概念を作り出したのも中島さんと言われていて、エンジニアにとっては神様のような人です。
そんな中島さんが仕事をする上で最も重要視していること、それは「スピード」です。
この本ではそんな仕事をする上で時間をどのように使うのか、について「ロケットスタート時間術」というメソッドを提言しています。
この本は
- 1章: なぜあなたの仕事が終わらないのか
- 2章: 「ロケットスタート時間術」を使うメリット
- 3章: 「ロケットスタート時間術」はどうやって生み出されたのか
- 4章以降: ノウハウ、具体的な方法
という形で進んでいくのですが、この章構成も所謂「ゴールデンサークル」と呼ばれる形式です。人にものを伝える時はWhy => How => Whatの順で伝えると心を動かしやすい、というものです。詳しくは以前書いたこちらのブログをどうぞ。
【思考整理】3年やってみた「空・雨・傘」方式を平成の終わりと共にマインドマップに変えてみた。 | Developers.IO
せーのでございます。GW、いかがおすごしでしょうか。私は久々に家族旅行に来ています。 現在朝7時30分。みんな疲れが溜まっているのか全く起きてこない。時間を持て余しているのでブログでも書いてみます。 今日はお休み、ということもあり、仕事の具体的な話ではなく、少し大まかな考え方のお話を共有したいと思います。 ...
このうち2章、3章は中島さんのマイクロソフト時代のエピソードが中心に書かれており、「読み物」として非常に面白いです。
例えばパーティに花を用意しておけと指示されたが雪で配達が遅れる事があった時、そのまま報告するとビル・ゲイツはものすごく怒る、とか、「ダブルクリック」は、塩を取ってほしい時に「すいません、塩を、、、」と最後まで言わない事と同じ、というオブジェクト指向の概念と似てる、という話は非常に興味深いのでおすすめします。
今回はこの本のうち「Why」に当たる1章と「What」に当たる4章以降をメインにご紹介します。
あなたの仕事が終わらないのは甘い見積もりでギリギリまでやらないから
1章では実際に中島さんが見てきた「仕事が終わらない人」を例に出し、どこがまずいのかを検証しています。
その結果、仕事が終わらない理由は
- 安請け合いするから
- ギリギリまでやらないから
- 計画の見積もりをしないから
の3点にまとめられます。その例として数学のテスト問題の例が出てきます。
数学のテストは前半は計算問題、後半は応用問題という構成が多いです。このうち応用問題はレベルがまちまちで、すぐ解ける場合と、延々時間を使う場合があります。仕事が終わらない人は得てしてこの後半の応用問題を甘くみているのです。なので全体の分量だけを見て「いつまでにできる」か決めてしまい、更にそれを時間的に等分に割って愚直に頭から解いていくため、応用問題で時間が足りなくなって完了しない、という分析でした。これはかなり説得力のある説だな、と思いました。
私も昔はビジネス書を小説と同じように頭から順番に文字を追って読んでいました。そうすると小説を読むのと同じくらい時間がかかる割に最初の方とかは忘れてるパターンが多いんですよね。
ビジネス書は
- 目次を読む
- 15分くらいでななめ読みする（ここでメモを取ることが多い）
- 読みたい所をじっくり読む
- もう一回さっと通す
という読み方だと頭にも入るし、かかる時間も30〜40分で終わります。これで物足りなかったら別の日にもう一回読めばいいんです。このような「本の読み方」について書かれたビジネス書もあるので、後日また紹介したいと思います。
遅読家のための読書術
はじめに なぜ「１ページ５分」の遅読家が年700本の書評家になれたのか？ 僕の読むスピードはどれくらい遅いか 元・遅読家として考えた 遅読家のための読書術 速読術というより、「正しい流し読み」 「読書量が減った！」の超シンプルな原因 どちらの「読み方」を選びますか？ 第１章 なぜ読むのが遅いのか？ ── フロー・リーディングの考え方 第２章 なぜ読む時間がないのか？ ── 月20冊の読書習慣をつくる方法 第３章 なぜ読んでも忘れるのか？ ── 読書体験をストックする極意 第４章 流し読みにもルールがある ── 要点を逃さない「サーチ読書法」 第５章 本とどう出会い、どう別れるか ── 700冊の選書・管理術 終章 多読家になって見えてきたこと ９歳のときの事故 父親が編集者なのに、読書に「苦手意識」が... 本なんか読まなくてもいい！ だから「読書生活」は楽しい 「教養のために読書」？ そんなのつまらない！ 印南敦史（いんなみ・あつし） 書評家、フリーランスライター、編集者。株式会社アンビエンス代表取締役。 1962年東京生まれ。広告代理店勤務時代に音楽ライターとなり、音楽雑誌の編集長を経て独立。 「1ページ5分」の超・遅読家だったにもかかわらず、ビジネスパーソンに人気のウェブ媒体「LifeHacker［日本版］」で書評欄を担当することになって以来、大量の本をすばやく読む方法を発見。 その後、ほかのウェブサイト「NewsWeek日本版」「Suzie」「WANI BOOKOUT」などでも書評欄を担当することになり、年間700冊以上という驚異的な読書量を誇る。 著書に『プロ書評家が教える 伝わる文章を書く技術』（KADOKAWA）のほか、音楽関連の著者が多数。
ちなみにこの章では、仕事が終わらない時に「もっと余裕を持っておけばよかった」と思うことは行動経済学的に証明されている、と「欠乏の行動経済学」という本を紹介しています。この本は前回も少し触れました「スラック」という考え方です。仕事術をたくさん読んでいるとこのように同じ理論が出てくることも多いです。
ということで、仕事が終わらない理由は「見積もりが甘いから」「ギリギリまでやらないから」「愚直に最初からやっていくから」ということがわかりました。では、どうすれば仕事が終わるようになるのでしょう。つまり、逆をやればいいんですよね。その具体的なメソッドについては第４章以降で語られています。見ていきましょう。
仕事が早く終わる方法
見積もりの調査期間をつくる
仕事がどれくらいでできるのか、という見積もりを感覚に頼ってはいけません。それは数学のテストをざっと眺めて「裏表1ページだから40分くらいで終わる」と言ってるようなものです。もしかしたら最後の問題が超難問なのかもしれないのです。
この本では頼まれた期間の2割を調査期間に当てろ、と提言しています。10日でやって欲しい、と言われたら「どのくらいかかるかやってみるのでスケジュールの割り出しに2日ください」と言う、というものです。
そしてここからがこの本のポイントです。
前半2割の時間で8割の仕事ができてなければリスケする
この2日間を使って猛烈にこの仕事に取り掛かり、2日終わった段階で仕事の8割が完了したという実感がない場合はスケジュールの調整を検討する、というものです。
10日の仕事が2日で8割できていなければリスケ。なかなか一般の感覚では納得しにくいものがありますが、それくらいの見積もり感で仕事をこなしていかないと「締切を確実に守る」という事はできない、と中島さんは言います。
その代わりその2日間はSNSやメールなどを一切断ち切り、仙人の如くこもってその仕事だけに集中する事が必要です。この集中を中島さんは「20倍界王拳」と例えていますが、簡単に言うと締切前日の夜に「やばい！このままじゃマジで間に合わない！」と焦って仕事をしている、あの状態です。あの集中を最初の2日に持ってくることで8割まで仕事を終わらせよう、ということです。
10日の仕事が5日で終わりそうでも提出は10日後
最初の2日で8割の仕事が終わっているわけですから、後は通常に流して仕事をしていても大きな問題がなければ5日くらいでその仕事が終わることが予想されます。
でもそこで終わりそうだからと力を入れて早めに終わらせてしまうと次の仕事を振られます。集中することは体力を大変使うので、休息も含めて残りの8日を流しながらゆるゆる仕上げていく。これが継続してパフォーマンスの高い仕事をするコツなんだそうです。これも先程でた「スラック」という考え方ですね。
パレートの法則を意識する
パレートの法則とは1896年にイタリアの経済学者 ヴィルフレド・パレートが論文で提唱したもので「物事は2割の要素が全体8割を構成している」というものです。例えば会社で言えば2割の優良顧客が売上の8割を占めていたり、逆にクレーム対応の8割は2割の顧客の相手をすることに費やされていたりする、ということです。先程の「全体の2割の期間で8割の仕事を終らせる」というのもパレートの法則ですね。
中島さんはこのパレートの法則を色々なところに取り入れています。例えば一日の仕事でも朝の2割の時間に集中して8割の仕事をこなし、午前中にはもう殆どの仕事が終わっている状態、午後はゆっくり流しながらメール対応などの作業を行っているそうです。
ただこれは上で言っている「最初の2日間」には当てはまりません。最初の2日間はとにかく朝から晩まで100%MAXの状態で働き、3日目以降、残りの2割の仕事をどうやってこなしていくか、という時間割にパレートの法則を使っています。
複数の仕事は縦に切った後横に切る
さて、この理論は確かに説得力があります。が、実際は可能なのでしょうか。普通に働いていて2日間誰とも連絡を取らず、メールも返さず仕事に没頭するのは実際にはかなり難しいです。まず2日間その仕事に没頭する、ということは他の仕事が完全に止まる、ということを指します。
その対策としてこの本では
- 長期の仕事は縦に切る
- 複数の仕事は横に切る
ということを提案しています。
1つ目はわかりやすいですね。要は大きなプロジェクトを小さなマイルストーンに分解して、更にそれを小さくタスク化していく、ということです。
2つ目ですが、これは先程の集中する時間を生み出すためのメソッドです。最初にタスクを1日に複数できるところまで縦に切って、その仕事を一日で並べていく、というものです。
例えば10日で終わらせるプロジェクトが2つ重なっているなら、タスクを5日間で終わるタスクにまで分割して一日の前半後半にそれぞれ並べる、ということです。大事なのはあくまでシングルタスクを意識して「その仕事を区切るまで他の仕事は考えない」ということです。
ただこの方法はあくまで「緊急避難だ」と中島さんは言います。あくまで1つの仕事が終わるまで別の仕事は入れない、というのが基本になります。これは経験上、開発系のエンジニアであれば意外と調整ができる感じじゃないでしょうか。
他人の仕事は遅れるものと思う
チームで仕事をしている時に別の人の作業待ちで自分の作業が止まることがあります。そんな時はモックアップを作ることをこの本では提案しています。エンジニアにはおなじみの考え方ですが「モックアップ」とは、要するになんちゃって的につくる模造品のことです。
誰かの作業待ちで止まる場合には、その人の作業が完成したことを想定したなんちゃって完成品をこちらで作って、その模造品と自分の作業を組み合わせるように仕事の続きをする、ということです。
これはプログラマであればおなじみの考え方なのでしっくりくる人も多いのではないでしょうか。Webサイトを作っていて、画面デザインが上がってこなければ、とりあえず入力フォームとボタンだけの画面をこちらで作ってから裏側のコードとつなげていく、というようなものです。実際に自分の作ったクラスの機能テストをする時にはダミーとして必ず固定の数字を返すモジュールを「モックアップ」と呼んだりしますよね。
結論は「まずやる」ということ
このように色々なメソッドを提示しているこの本ですが、全体を通して言われているのは
- すぐに取り掛かること
- 最初に全力を出すこと
です。Facebookのスローガンに「Done is better than perfect（完璧なことより終わっている事が重要だ）」というものがありますが、まさに大事なのは「締切までに終わらせること」であり、そのためにはまず取り掛かること、ロケットスタートが重要だ、というのが中島さんの信念です。まずやってみる。できるかできないかはその後判断する、というのはクラメソの考え方にも似ています。
この本の最後の章ではこんな事が書かれています。
あなたが今日から実践すべきこと、それは夜寝る前に、明日やることのタスクリストを作ることです。これをやらなければいけないのは「絶対」です。
そうです。あなたは明日の仕事の大半を、明日の午前中までには終わらせるのです。
大事なのは、今すぐに始めることなんですね。
まとめ
ということで「なぜ、あなたの仕事は終わらないのか」をご紹介しました。
実際にマイクロソフトやATOKといった企業に勤めていたこともあり、経験に基づいた実践的、理論的なメソッドが多いのか、と思っていましたが、意外に「崖を飛びながら飛行機を作る」というような気持ちの問題に触れている事柄も多かった印象です。
心理学では「楽しいから笑うのではない。笑うから楽しくなる」と言われます。まず行動を起こすことで気持ちがついていく部分もあることを身をもって経験しているからこそ「余裕を持つことの大事さ」を語っているのかな、と感じました。
なぜ、あなたの仕事は終わらないのか スピードは最強の武器である
【世界を一変させたWindows95の設計思想を生み出した伝説の日本人が教える 人生を制するスピード仕事術】 本書の著者、中島聡氏は、 「ドラッグ＆ドロップ」や「ダブルクリック」などの概念を生み出した 元マイクロソフトの伝説のプログラマーです。...
それではまた明日、お会いしましょう。
